I copied V1 code into my V2 project and it worked no problem. This approach seems to provide the least bumpy transition, imo. LGTM!

1. Is there is a technical reason to do this, such as a V2 user cannot also use V1?
2. Do we have actually have evidence that people are being driven to V1, (accepting that it can happen). Are the other ways such as documentation that we don't already have that can help this.
   • I did a web search on google / duck duck go / bing for "NATS dotnet client", "NATS dotnet nuget", "NATS C# client" and V2 is the most prominent, sometimes V1 isn't even on the first page.
   • Search for "NATS C# nuget" in google / ddg have V1 link on top but then V2 links. Bing has V2 on top.
   • The search results were clear that everything is part of NATS.IO.
3. We are going to have to maintain and improve V1 for at least 2 years if not 5, in which time, we won't have any issue with number 2.
4. Could this negatively affect existing V1 users. We've already pulled the rug out on them for the repo change (which I agree was necessary,) but they will have to change their nuget versioning to deal with version 2. Seems confusing.
5. We lose the granularity of versioning minor and patch applying specifically to v1 or v2.

1. Is there is a technical reason to do this, such as a V2 user cannot also use V1?

no. we're trying to leverage NATS.Client popularity to increase v2 / NATS .NET adoption.

2. Do we have actually have evidence that people are being driven to V1, (accepting that it can happen). Are the other ways such as documentation that we don't already have that can help this.

   • I did a web search on google / duck duck go / bing for "NATS dotnet client", "NATS dotnet nuget", "NATS C# client" and V2 is the most prominent, sometimes V1 isn't even on the first page.
   • Search for "NATS C# nuget" in google / ddg have V1 link on top but then V2 links. Bing has V2 on top.
   • The search results were clear that everything is part of NATS.IO.

it's confusing for people. search on https://www.nuget.org/

3. We are going to have to maintain and improve V1 for at least 2 years if not 5, in which time, we won't have any issue with number 2.

that is really what we're to do. trying to accelerate that time.

4. Could this negatively affect existing V1 users. We've already pulled the rug out on them for the repo change (which I agree was necessary,) but they will have to change their nuget versioning to deal with version 2. Seems confusing.

yes. it's v1 users who will be affected an need support, but once this is done then everyone will be on the same page more or less, rather than having confusing nuget packages for another 5 years.

5. We lose the granularity of versioning minor and patch applying specifically to v1 or v2.

that is true. we already have multiple packages with v2 and the management approach is to keep them all on the same version to avoid version compatibility matrix etc. I don't believe it would be a problem especially considering the release frequency of v1.

So I don't agree with the answers to (1) and (2). Based on web search, we know that it's not an issue. Based on Nuget, V1 comes up first in the listing, V2 is 4th, 5th and 6th, and matches the name NATS.Client which is really confusing to me since I would think that's part of V1. (Which I realize is an argument for the change, but that problem was created/pre-existing.)

(3) Doesn't matter where the code is, the customer is just putting the software in the field this year, 5 years doesn't seem out of the question.

(4) Maybe it won't negatively affect V1 users. Maybe it will actually encourage migration. I'm not actually sure how this pushes the needle either direction.

(5) Consider if you will, an application using 1.1.6 (the current V1). Now there are bug fixes and features that get added to v1 and we would have minor versioned it. 1.2.0 doesn't exist but 2.x.x does. Wait a second, I have to MAJOR version to get these fixes. At this point I'm unaware that the V1 api is fully supported in V2, and the changes are part of V2. This is a major barrier to entry, it's almost like support is completely gone. Sure, I could RTFM, but who does that. I think you see where I'm going.

At the end of the day 2 things. 1) Maybe I'm making a mountain out of a molehill, it wouldn't be the first time. 2) If the decision is to make this change, I'll live with it and I'll support it. There will or won't be issues, if there are we'll just deal with it.

I chatted with @mtmk for quite a while, and we agree that on this particular release it probably doesn't matter - however it does make semver not useful (except when tagging outdated). My preferred would be that 2.x doesn't include 1.x, and share the Nuget name, but are API major version change - either way there will be some issue either way.

Along the same lines as Alberto...

• Don't combine the repos (don't combine V1 into V2)
• Share the Nuget name

The upside of this is that V2 gets the benefit of V1 in the Nuget directory. The downside is that any V1 developer that has automatic updating of Nuget probably will fail a build. But I can't think of anyone who does that. Thinking about our 3 biggest corporate customers, they will never upgrade versions automatically, they will only ever upgrade to a specific version.

This also eliminates the semver issue as both will be completely independant.

Along the same lines as Alberto...

• Don't combine the repos (don't combine V1 into V2)
• Share the Nuget name

The upside of this is that V2 gets the benefit of V1 in the Nuget directory. The downside is that any V1 developer that has automatic updating of Nuget probably will fail a build. But I can't think of anyone who does that. Thinking about our 3 biggest corporate customers, they will never upgrade versions automatically, they will only ever upgrade to a specific version.

This also eliminates the semver issue as both will be completely independant.

This was the original suggestion now we came full circle back to #600

to reiterate this is making life easier for v1 users. some will try to update to latest. why break their code regardless of what we might think about semver?. second we will have to make sure we only publish a meta NATS.Client package from v2 not to break it for projects using both and users need to be careful with the versions numbers of NATS.Client and not use v2 of that package if mixing both APIs for some reason. Just to thrown in the mix they might be using other packages that require v1 and v2 which might lead to unresolvable package conflicts.

so the down side is we're going to make an extra release once in a while.

Along the same lines as Alberto...

• Don't combine the repos (don't combine V1 into V2)
• Share the Nuget name

The upside of this is that V2 gets the benefit of V1 in the Nuget directory. The downside is that any V1 developer that has automatic updating of Nuget probably will fail a build. But I can't think of anyone who does that. Thinking about our 3 biggest corporate customers, they will never upgrade versions automatically, they will only ever upgrade to a specific version.
This also eliminates the semver issue as both will be completely independent.

This was the original suggestion now we came full circle back to #600

to reiterate this is making life easier for v1 users. some will try to update to latest. why break their code regardless of what we might think about semver?. second we will have to make sure we only publish a meta NATS.Client package from v2 not to break it for projects using both and users need to be careful with the versions numbers of NATS.Client and not use v2 of that package if mixing both APIs for some reason. Just to thrown in the mix they might be using other packages that require v1 and v2 which might lead to unresolvable package conflicts.

so the down side is we're going to make an extra release once in a while.

DON'T Share the Nuget Name either

It is fine to not combine repos, but you cannot have namespace/dll/nuget collisions between the v1 and v2 client repos. If you do you cause the issue called out in #600 (comment) even if the version number is properly updated to 2.x or anything else since .Net only allows one dll to be named Nats.Client.dll. v1 can be Nats.Client and v2 can be Nats.Net just fine.

In larger companies, the library developers and service developers are often on different teams/orgs/regions and having nuget/dll overlaps can cause significant cost to the orgs when one team decides to begin using the v2 client and another team does not. Having an overlap effectively creates a production blocking bug to all .Net services that use NATS.

see #600